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(57) Abstract: A network element, or MBAS, for supporting mobility of mobile nodes (MN) in a system (MBN) which is connected 
to several different cellular bearer networks (BN) including unidirectional networks (DAB, DVB) and bidirectional networks (GSM, 
GPRS, UMTS). The MBAS is associated with at least one support area, each support area comprising one or more cells in the bearer 
networks (BN). The MBAS acts as a home agent to mobile nodes at home and as a foreign agent to visiting mobile nodes. The home 
agent and foreign agent functions are substantially compatible with mobile-IP protocol. The MBAS and the mobile node (MN) have 
a handover logic for handing over a mobile node to a neighbouring network element. The handover logic is adapted to provide 
continuous service for a mobile node after it has moved to the support area of the neighbouring network element and before it has 
re-registered with its home agent. 
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Handover in a multi -bearer-type network 

Background of the invention 

The invention relates to traffic management in a multi-bearer packet 
data network. A multi-bearer network, or an MBN, is a network having the ca- 
5 pability to carry a data packet via one of several alternative bearers. To be 
more precise, the term 'multi-bearer network' should be interpreted as mean- 
ing 'multi-bearer-type network', or in other words, a network arrangement 
which provides multiple different bearer types for data packet delivery. An ex- 
ample of an MBN is a concept known as MEMO (Multimedia Environment for 
10 Mobiles), see reference 1. Additionally, the MBN supports mobility of a sub- 
scriber terminal. An example of terminal mobility is IP mobility, which is the 
topic of standard RFC2002 by the Internet Engineering Task Force (IETF). 
This RFC standard is incorporated herein by reference. 

A general problem underlying the invention is how to select an op- 
15 timal bearer for each data packet in varying situations in a multi-bearer net- 
work. Data packets have different quality-of-service requirements. Situations 
may vary because the subscriber moves or the network load changes. A solu- 
tion to the general problem is disclosed in a co-pending patent application 
FI992850 which, however, is not published at the priority date of the present 
20 invention. Accordingly, the solution to the general problem is repeated here. 

Selecting the optimal bearer for a data packet between the MBN 
and the mobile node is based on a combination of 1) the quality-of-service re- 
quirement (traffic class) of the data packet in question, 2) the mobility data re- 
lated to the mobile node, 3) the traffic data related to the multiple bearers, and 
25 4) bearer preference information. The bearer preference information can be 
obtained from the mobile node, and optionally, from the operators of the home 
and visited MBN operators. It is possible to implement the above method by 
means of a single visitor administration system (VAS) which is a logical exten- 
sion of a foreign agent in the IP mobility scheme. Additionally, a network typi- 
30 cally comprises a home administration system (HAS) which is largely equiva- 
lent to a home agent in the IP mobility scheme. Later in this application, the 
single-VAS/HAS architecture will be referred to as 'simplified architecture'. 

A specific problem underlying the invention is how to perform a 
smooth handover between subnetworks of an MBN. A smooth handover is a 
35 handover with essentially no packet loss. A subnetwork is a part of a network 
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which is under one foreign agent (FA). In conventional mobile IP, a handover 
between subnetwork under different foreign agents requires registration with 
the mobile node's home agent (HA) and foreign agent. The (re)registration of a 
mobile node means that the mobile node registers with its new foreign agent 
5 and its home agent. The mobile node must register its new care-of-address (ie 
the address of its new foreign agent) into the mobile node's mobility binding 
list in its home agent. In mobile IP, the re-registration is necessary because 
only by re-registration can the mobile node's home agent redirect IP traffic to 
the new foreign agent of the mobile node. The re-registration is a time- 
10 consuming process during which a fast-moving node may move completely 
out of the coverage area of the old cell before receiving service from the new 
cell. As a result, some packets may be lost. A similar problem exists in other 
wireless IP networks. 

Brief summary of the invention 

15 The object of the invention to solve the specific problem relating to 

handovers in mobile-IP networks. A preferred embodiment of the invention, 
referred to as 'enhanced architecture', provides a solution for the handover- 
related problem. The enhanced architecture is based on the idea that during 
handover, an administration system (AS) acts as a foreign agent for all mobile 

20 nodes staying in the cells controlled by the AS. The AS forwards data packets 
to correct interface units (by routing or tunnelling, depending on whether there 
is a physical or logical link, respectively, between the administration system 
and the interface units). The AS has a mobility management function for sup- 
porting mobility between cells controlled by the AS and border cells of a 

25 neighbouring AS. Handover between cells under one AS is performed locally, 
and there is no need for authentication and re-registration with the home 
agent. In a handover between two administration systems belonging to one 
operator, there is a trust relationship, and the new administration system 
makes use of the authentication performed by the old administration system 

30 (or the first one which authenticated the mobile node). By temporarily replac- 
ing the conventional re-registration process with this trust relationship, hando- 
vers between administration systems can be streamlined, and packet loss is 
kept to a minimum. 

According to a further preferred embodiment, the functions of the 

35 home administration system (HAS) and the visitor administration system (VAS) 
are combined into a single functional entity or network element, which will be 
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referred to as a multi-bearer administration system (MBAS). A network may 
comprise more than one MBAS elements. A system according to the en- 
hanced architecture provides better scalability and other benefits, which will be 
apparent after reading the detailed description. 
5 In order to save the battery of a portable mobile node, it is prefer- 

able that the mobile node only monitors one bearer type (network) at a time. 
For example, the subscriber data related to the mobile node can include a 
default bearer type, such as GSM or UMTS. The mobile node should be 
paged on this bearer. The mobile node can be ordered to monitor the selected 

10 bearer type by sending a modified page message which indicates the selected 
bearer type, channel, possible decryption data, etc. Alternatively, such infor- 
mation can be sent in a separate message, such as a short message, USSD, 
(Unstructured Supplementary Service Data), data call or the like. 

According to another preferred embodiment of the invention, as 

15 long as the mobile node is within a certain coverage area, all IP packets be- 
longing to the same session (or flow if flow labels are used) are routed via the 
same interface unit. For example, if a mobile node is receiving IP packets from 
a DAB network, via a cell x, all IP packets of the same session should be 
routed via DAB cell x, unless the mobile node moves out of the coverage area 

20 of this cell. 

Brief description of the drawings 

The method and the apparatus according to the invention will be 
described in more detail by means of preferred embodiments with reference to 
the appended drawing in which: 
25 Figure 1A shows the overall concept of the simplified architecture 

according to the invention and the available options for mobile node- 
terminated (downlink) traffic; 

Figure 1B shows the available options for mobile node-originated 
(uplink) traffic; 

30 Figure 2 shows the major functional blocks of a visitor administra- 

tion system; 

Figures 3A and 3B show the internal structure of the visitor admini- 
stration system VAS in more detail; 

Figure 4 illustrates the cooperation between a traffic management 
35 unit TMU and a traffic distribution unit; and 
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Figure 5 shows a preferred version of a routing table with two op- 
tional fields; 

Figure 6 illustrates the procedures performed by a traffic manage- 
ment unit after receiving an IP packet; 
5 Figure 7 illustrates the hierarchical structure on an enhanced multi- 

bearer network MBN by means of an abstract model; 

Figures 8A and 8B show the internal structure of the multi-bearer 
administration system MBAS in more detail; 

Figure 9 shows the logical links between the MBAS elements and 
10 the network interface units; 

Figures 10 and 11 illustrate broadcasting the ID number of the 
MBAS element via broadcast and non-broadcast networks, respectively; 

Figure 12 shows a preferred internal structure of an MBAS element; 

Figure 13 shows a preferred internal structure of an interface unit; 
15 Figure 14 illustrates traffic flow for uplink user traffic; 

Figures 15A and 15B illustrate traffic flow for downlink user traffic; 

Figure 16 illustrates an intra-MBAS handover between two DVB 

cells; and 

Figures 17A and 17B illustrate an inter-MBAS handover between 
20 two DVB cells. 

Detailed description of the invention 

Simplified Architecture 

Figure 1A shows a preferred structure of a network arrangement in 
which the invention can be used. A mobile node MN communicates with its 

25 correspondent node MCN via a multi-bearer network MBN which offers several 
alternative bearers for a data packet DP. Each data packet comprises a 
header H and a payload part PL. To be precise, a data packet typically has 
several headers inside each other, because each protocol layer inserts its own 
header. However, each protocol layer only handles each own header, and a 

30 model with only one network layer header is usually sufficient for describing 
the invention. The header indicates, directly or indirectly, a quality-of-service 
requirement QoS for the data packet. An example of a direct QoS indication is 
a case where the data packet header includes a parameter which is or which 
can be directly mapped to a quality-of-service requirement parameter. An ex- 

35 ample of an indirect QoS indication is a case where the header indicates a 
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PDP (packet data protocol) context, and the PDP context in turn indicates the 
QoS requirement. It should be understood, that 'quality of service' is a very 
generic term indicating certain requested or negotiated transmission charac- 
teristics, such as bit rate, maximum delay and/or packet loss probability. De- 
5 pending on the actual protocol used, quality of service is indicated by or 
mapped to one of the existing appropriate fields, such as the Traffic Class field 
of IPv6 or the Type of Service of IPv4. The term 'traffic class' is used to refer 
collectively to the fields which are used to indicate the qua!ity-of-service re- 
quirement. 

10 In Figure 1A, it has been assumed that the MBN communicates with 

the MCN via the Internet. There is preferably a firewall FW at the edge of the 
MBN. A gateway node GW interfaces the MBN to the Internet. A backbone 
network BBN combines the different bearer networks BN. It may be the MBN 
operator's internal network. A physical example of a BBN is a high-speed lo- 

15 cal-area network or a wide-area network. A home administration system HAS 
is largely equivalent to a home agent in the IP mobility scheme (described in 
the RFC 2002). A visitor administration system VAS is a logical extension of a 
foreign agent in the IP mobility scheme. The MBN has access to several bear- 
ers for conveying the data packet to the mobile node MN. 

20 The bearers include a first set of bidirectional bearers. Examples of 

bidirectional bearers are circuit-switched mobile networks, such as GSM 
(Global System for Mobile communications), and packet-switched mobile net- 
works, such as GPRS (General Packet Radio Service), and third generation 
mobile networks, such as UMTS (Universal Mobile Telecommunications Sys- 

25 tern), which offer both circuit-switched and packet-switched bearers. For each 
bidirectional bearer, there is a corresponding interface unit GSMJU, GPRSJU 
and UMTSJU. 

The bearers include a second set of unidirectional bearers. Exam- 
ples of unidirectional bearers are digital audio broadcast (DAB) and digital 
30 video broadcast (DVB). For both DAB and DVB, Figure 1 shows two cells 
DAB_C1, DAB_C2; DVB_C1, DVB_C2, and their corresponding interface units 
DABJU1, DABJU2; DVBJU1, DVBJU2. 

The set of unidirectional bearers can also be called broadcast bear- 
ers, and the set of bidirectional bearers can also be called non-broadcast 
35 bearers. 
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In the system of Figure 1, there is another difference between the 
first and second set of bearers. In addition to being bidirectional, the bearers of 
the first set are point-to-point bearers. In other words, each connection is cus- 
tomized to one particular recipient. In contrast, the bearers of the second set 
5 are broadcast or multicast bearers. In other words, it is not immediately appar- 
ent how a connection can be customized to individual recipients. One solution 
to this problem is encryption of the broadcast/multicast bearers with distribu- 
tion of decryption keys only to the intended recipients. 

Within the context of this application, 'uplink' means from the mobile 

10 node MN to the correspondent node MCN and 'downlink' means the inverse 
direction. The bold arrows in Figure 1 depict various routing options for data 
packets in the downlink direction. For the span 12 between the MCN and the 
VAS, data packets are routed directly if the IP address of the mobile node MN 
(or its subscriber) does not belong to the MBN network. If the IP address be- 

15 longs to the MBN network, data packets are routed via the home administra- 
tion system HAS. This route is drawn with a thin dotted line 11. For the span 
12 between the VAS and the MN, the VAS has several alternative bearers. 
According to the invention, the VAS considers all of the following: 1) the qual- 
ity-of-service requirement (the traffic class) of the data packet in question, 2) 

20 the mobility data related to the mobile node (i.e., which bearers and which in- 
terface units can be used to reach the MN), 3) the traffic load/resource avail- 
ability data related to the multiple bearers, and 4) bearer preference informa- 
tion. The optimal bearer selection and the internal structure of the VAS will be 
described later in more detail. 

25 Figure 1B shows the available bearer options for uplink traffic be- 

tween the MN and the MCN. Because the DAB and DVB bearers are unidirec- 
tional (downlink only), they are not available for uplink traffic, and the only 
available bearers 21a to 21c are via the mobile networks GSM, GPRS and 
UMTS. 

30 Figure 2 shows the major functional blocks of a visitor administra- 

tion system VAS. The VAS has three main functions or sections: 1) a mobility 
management function MMF, 2) a traffic management function TMF, and 3) a 
caching proxy CP. The mobility management function MMF of the VAS is 
largely equivalent to a foreign agent in the IP mobility scheme of RFC 2002. 

35 The MMF may also participate in authentication and/or charging. The functions 
of the traffic management function TMF include a) collecting traffic information 
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from the various bearer networks (GSM, GPRS, UMTS, DAB, DVB...), b) col- 
lecting traffic management-related information from the mobile node MN and 
its home MBN, c) sending traffic management-related messages to the mobile 
node MN, d) selecting the bearer network for downlink traffic, and e) forward- 
5 ing downlink traffic to the selected bearer network. The extended TCP pro- 
posed in reference 1 can be used for this purpose. The function of the caching 
proxy CP is to maintain frequently-requested content in high-speed memory in 
order to minimize retrieval of such content over telecommunication lines. The 
caching proxy CP should have enough intelligence to handle data packets in 
10 an application-specific manner, instead of merely caching IP traffic packets. 

Figures 3A and 3B show the internal structure of the visitor admini- 
stration system VAS in more detail from the point of view of traffic manage- 
ment. Figure 3A shows the VAS structure from the point of view of user traffic. 

IP Routing Software blocks 31 to 33 route data packets to the ap- 
15 propriate recipients, based on the packet headers. These blocks also decap- 
sulate IP packets towards the VAS and pass the decapsulated packets to the 
upper layers for further processing. Correspondingly, the blocks 31 to 33 also 
encapsulate packets arriving from the upper layers. In Figures 3A and 3B, the 
packets from the upper layers are indicated as the traffic flow entering the 
20 blocks 31 to 33 from above. The VAS also comprises a traffic distribution unit 
TDU. The function of the TDU is a) to determine the traffic class of incoming IP 
packets based on one or more quality-of-service related parameters indicated 
by the packet header (these parameters may comprise Type of Service' for 
IPv4 and Traffic Class' or 'flow label' for IPv6), b) based on the traffic 
25 class/QoS requirement, to select an appropriate bearer (radio network) for 
downlink traffic, and c) to encapsulate each IP packet into an outer IP header 
towards the selected bearer network and interface unit. The fact that the arrow 
from the TDU enters IP routing block 32 from below indicates that the TDU has 
already encapsulated the IP packets, and the block 32 should not perform an- 
30 other encapsulation. 

Figure 3B shows the VAS structure from the point of view of system 
traffic, mobility management and traffic management. A mobility management 
unit MMU performs the functions which are normally performed by a foreign 
agent in an IP network with mobile IP support, with some enhanced function- 
35 ality related to MBN support, such as cell selection and handover control 
within a broadcast network or between networks. The function of the traffic 
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management unit TMU is a) to collect traffic load information from the various 
bearer networks BN (DVB, DAB, UMTS, etc.), b) to collect and to update (via 
the MMU) bearer preference information from the mobile nodes, c) optionally 
to collect bearer type preference information from the home network of each 
5 mobile node, d) to create and update bearer routing information to the TDU, 
and e) to send traffic administrative messages to the mobile nodes. For per- 
forming these functions, the traffic management unit TMU receives the follow- 
ing input: a) traffic load information from the various bearer networks BN, b) 
bearer preference information from the mobile nodes, and c) optionally bearer 
10 type preference information from the home MBN of each mobile node. The 
traffic distribution unit TDU and the traffic management unit TMU cooperate to 
perform the traffic management function TMF shown in Figure 2. The coop- 
eration of the TDU and the TMU will be described in more detail in connection 
with Figure 4. 

15 Figure 4 illustrates the cooperation between the traffic management 

unit TMU and the traffic distribution unit TDU. The traffic management unit 
TMU considers three kinds of information: 1) traffic load information 41 from 
the various bearer networks BN, 2) available interface unit information 42 and 
3) preferred bearer type 43. The traffic information 41 from the various bearer 

20 networks BN indicates the load (or inversely: the available capacity) on the 
alternative bearer networks. This information may be used as a basis for hard 
decisions (whether or not a requested bearer can be allocated) or for soft de- 
cisions (whether or not tariffs should be adjusted to promote the use of lightly 
loaded bearer networks). The available interface unit information 42 can be 

25 generated as follows. A preferred interface unit table PIU indicates for each 
bearer type (DVB, DAB, UMTS, GPRS and GSM) one or more preferred in- 
terface units (or to be more precise the IP addresses of the preferred interface 
units) and their rank of preference. The PIU table is mobile-node-specific. 
Each mobile node MN should directly or indirectly indicate its PIU table during 

30 registration and in connection with location updates. For example, an MN may 
indicate the PIU directly by forming and sending the PIU table to the VAS. The 
PIU table is not sent to the TMU directly, however. Instead, the mobility man- 
agement unit MMU controls handover within and between the networks. Ac- 
cordingly, the MMU also selects the interface unit for each broadcast network. 

35 The MMU considers the PIU and the mobility data related to the mobile node 
(i.e., what interface unit can be used to reach the MN). The MMU uses this 
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information to create an available interface unit table AIU which is then applied 
to the TMU (instead of the PIU table as such). The preferred bearer type in- 
formation 43 can be organized as a table of a preferred bearer type PBT. The 
PBT table indicates, for each traffic class, several alternative bearer types with 
5 decreasing preference. The acronym WLAN' stands for wireless local-area 
network, although such a network is not shown separately in Figures 1A and 
1B. For example, for traffic class 1, the most preferred bearer types are WLAN 
and UMTS, but GPRS and GSM are also possible choices. The VAS may ob- 
tain a home-MBN-specific PBT table in connection with MN registration, or it 
10 may use a generic default PBT table. 

The traffic management unit TMU considers all the available infor- 
mation 41 through 43, and creates and updates a Multi-Bearer Routing Table 
MBRT in the traffic distribution unit TDU. The MBRT indicates the IP address 
of the appropriate interface unit for each combination of active user w, w+1 , 

15 etc. and traffic class 1 through 5 (the number 5 being just one example). It 
should be noted that a user with multiple simultaneous sessions can have an 
entry for each session in the MBRT table. When the traffic distribution unit 
TDU receives a data packet whose header H indirectly indicates a traffic class 
(via a QoS-related parameter), the TDU uses the corresponding user ID and 

20 the traffic class to retrieve the IP address of the appropriate interface from the 
Multi-Bearer Routing Table MBRT. Next, the TDU encapsulates the data 
packet DP into another data packet DP 1 whose header FT indicates the IP ad- 
dress (of the selected interface unit) which was retrieved from the MBRT. 
When the selected interface unit receives the data packet DP', it decapsulates 

25 the outer header FT and sends the original data packet DP to the mobile node 
MN. An advantage of an MBRT table substantially as shown in Figure 4 is that 
it directly indicates, for each data packet, the IP address to which the packet is 
to be sent. In other words, sending an individual data packet involves no deci- 
sion-making, just a retrieval of an IP address from the MBRT table. 

30 For IPv6, the traffic class can be mapped to Preference. For IPv4, 

the traffic class can be mapped to Type of Service. If the Differentiated Serv- 
ices protocol is used, traffic class can be mapped to bits reserved for future 
use. According to a preferred embodiment of the invention, for IPv6, all pack- 
ets with identical flow labels are usually mapped identically. 

35 Let us assume that a user w has three simultaneous applications: 

news, FTP and video on demand. The IP packets from the MCN to this user 
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may have a preference/priority value of 1 for news, 4 for FTP and 9 for video. 
The PIU and PBT tables are as shown in Figure 4 and the MBN uses five traf- 
fic classes, and the mapping between the preference value and the traffic 
class is as follows: 



5 



Traffic class value in IPv6 header 


Traffic class in Multi-bearer network 


1 -2 


1 


3 


2 


4 - 7 


3 


8-11 


4 


12 - 15 


5 



In such a case, the IP packets carrying news belong to traffic class 
1, and they are routed via the router whose IP address is IP-GPRS JUa. The 
IP packets carrying FTP belong to traffic class 3, and they are routed via the 
router whose IP address is IP-DABJUx. The IP packets carrying video belong 
10 to traffic class 4, and they are routed via the router whose IP address is IP- 
DABJUx. 

Let us now assume that the user w starts yet another application, 
such as e-mail having a preference value of 2. In this case, IP packets carry- 
ing e-mail belong to traffic class 1, and they are routed via the router whose IP 

15 address is IP-GPRSJUa. 

Figure 5 shows yet another preferred feature or addition to the em- 
bodiment shown in Figure 4. This preferred feature allows paging the mobile 
node via a single default bearer and using a single interface unit as long as the 
mobile node is within its coverage area. The feature is based on the idea that 

20 IP packets separated by a time interval exceeding a certain maximum time 
Tmax are treated by the MBN as belonging to two separate sessions. In this 
case, each entry in the MBRT table includes not only the IP address of the 
relevant interface unit but also a busy flag B and a timer field T. The timer field 
T is compared with the maximum value Tmax, the value of which is optimized 

25 by the operator. If the busy flag B is zero, it means that no IP packets used 
this entry for the past time interval of Tmax. If the busy flag B is set (indicated 
in Figure 6 with 'B=1'), it means that at least one IP packet used this entry for 
the past time interval of Tmax. The value of each timer field T is incremented 
by the TMU in a constant time interval. Each time an IP packet is routed by 

30 using a certain entry in the MBRT table, the corresponding timer field T of that 
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entry is reset to zero and the busy flag is set to one. Setting the busy flag to T 
is preferably performed or triggered by the TDU when it routes an IP packet. 

Figure 6 shows a way to use the B and T fields shown in Figure 5. 
In step 61 , the traffic distribution unit TDU examines the header of an incoming 
5 IP packet. The TDU determines the destination IP address and traffic class 
(direct or indirect mapping) and retrieves the corresponding entry from the 
MBRT table. In step 62, the TDU checks the busy flag B to see if the selected 
interface unit IU has been used by this user/session during the last time inter- 
val Tmax. If not. then in step 63 the TDU begins to buffer incoming IP packets 

10 and in step 64 the TDU pages the mobile node. More preferably, to reduce the 
computational load of the TDU, the TDU can only trigger a page while the ac- 
tual page operation is performed by another unit, such as the TMU. In step 65, 
when the page operation is complete and the mobile node responds, the busy 
flag T is set to one and the timer field T is initialized to zero. In step 66, the 

15 TDU begins encapsulating each original IP packet with another IP header 
whose destination IP address is retrieved from the MBRT table. Finally, in step 
67, the encapsulated IP packets are delivered via the IP routing software to 
the mobile node. 

The traffic management unit TMU is responsible for updating the 
20 MBRT. The MBRT updating should obey the following principles. An entry of 
the MBRT table, or more specifically, the IP address for a certain combination 
of a user/session and a traffic class, can only be modified under the following 
circumstances: If the busy flag B is nonzero, the IP address can be updated if 
a) the modification is caused by a handover between cells of a broadcast net- 
25 work or between different networks, b) the mobile node moves out of the cov- 
erage area of one bearer, or c) the traffic load/resource availability changes. 
On the other hand, if the busy flag B is zero, the IP address can be updated if 
a) the modification is caused by a handover between cells of a broadcast net- 
work, b) the mobile node moves out of the coverage area of one bearer, or c) 
30 there is an extraordinary change of traffic condition. Interruption of IP traffic 
flow should be avoided, if possible. This is particularly important with IP pack- 
ets having high QoS requirements. Inversely, flows with low QoS requirements 
should be interrupted first, if interruptions cannot be avoided. Obeying these 
principles allows the use of the same interface unit as long as possible. 
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Enhanced Architecture 

The embodiment described under 'Simplified architecture' leaves 
some questions unanswered. Most notably, a single VAS can be a perform- 
ance bottleneck. Scalability is not achieved by simply installing more VAS 
5 elements, because the simplified architecture comprises no mechanisms for 
inter-VAS handovers. 

An essential feature of the enhanced architecture is the ability to 
support multiple administration systems, such as the MBAS elements. Each 
MBAS element is responsible for the delivery of IP packets to a group of home 
10 users (as a home agent) and a group of visited users (as a foreign agent). For 
example, an MBAS in Helsinki acts as a home agent for Helsinki-based sub- 
scribers. When these users are away from Helsinki, the MBAS forwards their 
traffic to the relevant foreign network. The same MBAS acts as a foreign agent 
for users whose home network is elsewhere but who are currently roaming in 
15 Helsinki. 

Figure 7 illustrates the hierarchical structure of an enhanced multi- 
bearer network MBN by means of an abstract model. In Figure 7, reference 
signs AS1 and AS2 denote administration systems which are essentially for- 
eign agents (FA) with an extended mobility support function. In the MBN, the 

20 AS can be like the visitor administration system VAS described in connection 
with the simplified architecture, or an enhanced multi-bearer administration 
system MBAS. Reference signs AP1a to AP2b denote access points. In the 
multi-bearer network MBN, they represent interface units of broadcast net- 
works. Reference signs 71 denote conventional hierarchical connections be- 

25 tween administration systems AS and access points AP. These connections 
are drawn with solid lines. Conventional mobile IP suffers from the drawback 
that a mobile node MN must register with its home agent before receiving any 
services if it moves from one access point to another, if the access points are 
under different foreign agents. This is why the enhanced architecture of the in- 

30 vention makes use of connections 72, shown as dotted lines. The connections 
72 are used primarily to provide continuous support for a mobile node during 
an inter-AS handover, for example a handover from a cell 73 under access 
point AP1b to a cell 74 under access point AP2a. Without the connections 72 f 
the high-level architecture of Figure 7 closely resembles that of some existing 

35 wireless IP networks. Traffic on connections 72 is more restricted than traffic 
on connections 71. For instance, the connections 72 are not allowed to be 
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used for establishing new sessions, and the lifetime of a connection is limited 
to a short period after an inter-AS handover until the mobile node registers 
with its new foreign agent and updates its mobility binding in its home agent. 

Figures 8A and 8B show the internal structure of the multi-bearer 
5 administration system MBAS in more detail. In terms of hardware, a typical 
implementation of the MBAS element resembles a suitably conFigured pow- 
erful router. The novel features of this invention can be implemented by soft- 
ware routines. The most notable difference between the MBAS shown in Fig- 
ures 8A and 8B and the VAS shown in Figures 2, 3A and 3B is the fact that 
10 the MBAS is a combination of a VAS and a HAS. It also includes the home 
agent and foreign agent functions, HA and FA, which are largely equivalent to 
the corresponding functions within the Mobile-IP scheme. To be more precise, 
the home agent function in a home MBAS according to the invention corre- 
sponds to the home agent of the mobile IP. Correspondingly, the foreign agent 
15 function in a visited MBAS according to the invention corresponds to the for- 
eign agent of mobile IP. Reference sign HL points commonly to blocks MMU. 
HA and FA which constitute the handover logic within the MBAS. 

Figure 9 shows the logical links between the MBAS elements and 
the network interface units. Each MBAS element should be physically or logi- 
20 cally attached to only one interface unit of each non-broadcast (bi-directional) 
bearer network (GSM, GPRS or UMTS). However, an MBAS element can be 
physically or logically attached to several interface units of each broadcast 
(unidirectional) bearer network. Figure 9 shows several interface units xxJU, 
where 'xx' is the name of a bearer network, such as DAB, DVB, GSM, GPRS 
25 or UMTS. Each interface unit is responsible for the delivery of data packets to 
a network selected by the MBAS. Each GSM interface unit GSMJU can be 
connected to an interworking unit (IWU, not shown separately) in a GSM net- 
work. Each GPRS/UMTS interface unit GPRSJU, UMTSJU can be con- 
nected to a gateway support node (GGSN, not shown separately) in a GPRS 
30 or UMTS network. The embodiments shown in the Figures comprise a sepa- 
rate interface unit (DABJU, DVBJU) for each cell in a broadcast network 
(DAB and DVB) because these networks do not support IP routing. In contrast, 
the bidirectional networks (GSM, GPRS and UMTS) do support IP routing, and 
for each of these networks there is an interface unit which is common to all 
35 cells of the network. In other words, each MBAS has one interface unit for 
each network with IP routing capability and one interface unit for each cell in a 
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network without IP routing capability. Strictly speaking, GSM infrastructure 
does not support IP routing directly, but a similar function can be achieved by 
the PPP (point-to-point protocol) between the MBAS and a mobile station. By 
conveying IP packets on top of the PPP, packets can be delivered to any cell 
5 under the MBAS. As shown in Figure 9, an MBAS element MBAS1 is con- 
nected to each bi-directional bearer network UMTS, GSM and GPRS via in- 
terface units 911, 912 and 913 respectively. In contrast, the embodiment 
shown in Figure 9 has a separate interface unit for each cell in the unidirec- 
tional networks DVB and DAB. In this case, interface units 914 and 915 each 
10 serve one DVB cell and interface units 916 and 917 each serve one DAB cell. 

The invention preferably makes use of concepts 'master MBAS' and 
'MBAS-area'. Each DAB or DVB cell is physically or logically connected to its 
nearest MBAS element. 'Nearest' can be interpreted as being the geographi- 
cally closest (for example, by means of a look-up table) or as having the 
15 smallest number of hops via its interface unit. The nearest MBAS acts as a 
master MBAS for the cells to which it is the nearest MBAS. For example in 
Figure 9, MBAS1 is the nearest MBAS for DVB interface units 914 and 915 
and DAB interface units 916 and 917. Thus MBAS1 is the master MBAS for 
DVB cells 924 and 925 and DAB cells 926 and 927. These cells, which are 
20 under one master MBAS, form an MBAS support area, or simply 'MBAS area'. 
It should be noted that an MBAS area does not necessarily have one clearly 
defined geographical border. Because the sizes of DVB cells and DAB cells 
can be different, a certain location, such as the location 950, can have MBAS1 
as its master MBAS for DAB but MBAS2 as its master MBAS for DVB. In other 
25 words, the geographical border of an MBAS area may differ between the 
bearer networks, and an MBAS supporting five bearer networks (GSM, GPRS, 
UMTS, DAB and DVB) may have five different MBAS areas. 

For each cell, only its master MBAS is allowed to grant a new ses- 
sion to start in it. Other MBAS elements, even if they are physically or logically 
30 connected to the cell, can only grant traffic routing via this cell in a handover 
situation. The resources (total bandwidth, time in use after a handover...) allo- 
cated to a non-master MBAS are limited. Most resources of a cell are allocated 
to its master MBAS. 

It is not necessary to connect every cell to several MBAS elements. 
35 Only those cells that are located along the border of two MBAS areas should 
be physically or logically connected to several MBAS elements. Connecting a 
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border cell to more than one MBAS element facilitates a smooth handover 
between two different MBAS areas. 

Because GSM, GPRS and UMTS networks have inherent routing 
and handover capability, it is not necessary to employ the concepts of master 
5 MBAS' and 'MBAS area' in these networks, unless the ID of an MBAS is 
broadcast in these networks. !n this case, an MBAS area comprises the cells 
broadcasting its ID. An MBAS is a master MBAS to such cells. 

Each cell in a broadcast network (DAB, DVB) has a unique ID 
(identifier) number. Each DAB or DVB cell broadcasts its own ID number peri- 

10 odically. Based on this ID number, the IP address of the corresponding inter- 
face unit xx_IU can be determined. For example, each MBAS may store a 
look-up table which maps a cell ID to an IP address of an interface unit. When 
a mobile node registers with an MBAS, the MBAS can send this information to 
the mobile node. The look-up table stored in each MBAS should contain the 

15 information of all cells in this MBAS area as well as in the neighbouring MBAS 
area. 

Each MBAS element should also broadcast its IP address or ID 
number. If the ID number is broadcast, each MBAS should also have a unique 
number, based on which the IP address of the MBAS can be determined. For 

20 example, in each MBN, there can be a look-up table which maps a cell ID to 
an IP address. The element storing the look-up table is called an ID storage 
device. Each MBN should also store a look-up table of other networks whose 
operators have a roaming agreement with the operator of the home network. 
Only the look-up table of the currently visited (home or foreign) network needs 

25 to be stored in the mobile node. Upon entering a new MBN, a mobile node can 
request the ID storage device of its home network to send the look-up table of 
the new MBN. The request may contain an unknown MBAS ID that is broad- 
cast in the new MBN. The ID storage device of the home network finds the 
corresponding look-up table and sends it to the mobile node. The request is 

30 conveyed via the bidirectional network directly (not via the MBN). Optionally, a 
mobile node can cache several look-up tables of frequently visited MBNs. 

Figures 10 and 11 illustrate broadcasting the ID number of the 
MBAS element in broadcast and non-broadcast networks, respectively. Be- 
cause each non-broadcast interface unit (GSMJU, GPRSJU and UMTSJU) 

35 is (logically or physically) linked to only one MBAS element, there is no need to 
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broadcast the ID number of those interface units. The IP address of those 
units can be derived directly from the ID number of the MBAS. 

The various network elements will now be described in more detail. 
The MBAS elements are adapted 1) to attract and intercept datagrams that 
5 are destined to the home address of any of its registered mobile nodes (ie to 
act as a home agent, preferably supporting route optimization); 2) to forward 
traffic to mobile nodes that are in their home networks (via a traffic distribution 
unit TDU, see Figure 3A) or away from their home networks (to act as a for- 
eign agent.); 3) to select an appropriate bearer type for each session; 4) to as- 

10 sist mobile nodes in inter-cell handovers (especially in broadcast networks) 
and inter-MBAS handovers; and 5) to act as a caching proxy. Figure 12 shows 
a preferred internal structure of an MBAS. The four leftmost elements, ie the 
CP, the MMU, the TMU and the TDU have already been described in connec- 
tion with Figures 2, 3A and 3B. The foreign and home agent functions, FA and 

15 HA ( are largely equivalent to the corresponding the functions in the known IP 
mobility scheme. 

Figure 13 shows a preferred internal structure of an interface unit 
xx_JU. The interface units have a Protocol Adaptation function PA to encap- 
sulate incoming IP packets into protocols suitable for the radio bearer, for ex- 

20 ample to encapsulate IP packets over MPE&section&MPEG2 TS protocols for 
transferring them via a DVB network. A Traffic Control function TC controls in- 
coming traffic, limits the traffic from each MBAS and discards packets from 
unidentified sources. A Resource Management function RM monitors, reports 
on and controls the use of resources allocated to the interface unit. 

25 Figures 14 ? 15A and 15B illustrate traffic flow for user traffic. As 

stated, each operator may have one or more MBAS elements in a multi-bearer 
network. Each MBAS is responsible for handling a group of users. Each MBAS 
broadcasts its ID number in its MBAS area. From the ID number of the MBAS, 
a mobile node MN is able to determine the IP address of the MBAS. Alterna- 

30 tively, it is also possible to broadcast the IP address of the MBAS elements. 

After obtaining the IP address of its visited MBAS, a mobile node 
has to perform registration with its home MBAS as well as the visited MBAS 
before receiving any multi-bearer services. The registration procedure is basi- 
cally similar to the one in the mobile IP scheme. A mobile node has to register 

35 even if it is in its home network. 
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Because the broadcast cells overlap, there are likely to be locations 
in which a mobile node can receive different MBAS ID numbers from different 
cells. In this case, a mobile node should select the MBAS whose ID is broad- 
cast in an active cell, or in other words, the broadcast cell which is being or 
5 going to be used for transferring the downlink traffic of the mobile node. How- 
ever, in some circumstances, for example during a handover of an ongoing 
data call, or when a mobile node is moving around a border area, the mobile 
node can be attached to a visited MBAS whose ID is different from the one 
broadcast in the active cell. 

1 o Figure 14 illustrates traffic flow for uplink user traffic. Uplink user 

traffic is transmitted from the mobile node MN via one or more of the bidirec- 
tional networks to the visited MBAS which forwards the traffic via the gateway 
GW and the Internet to the mobile node's correspondent node MCN. 

Figure 15A illustrates downlink user traffic flow from the correspond 

15 dent node MCN to the MBAS. Downlink traffic is delivered to the visited MBAS 
directly if the mobile node is under its home MBAS (its home MBAS and vis- 
ited MBAS are the same), or if route optimization is used. This case is shown 
with a solid arrow 151. Downlink traffic is delivered to the visited MBAS via the 
mobile node's home MBAS if the mobile node is away from its home network 

20 and route optimization is not used. This case is shown with a dotted arrow 
152. 

Figure 15B illustrates downlink user traffic flow from the MBAS to 
the mobile node MN. Downlink traffic is delivered from the visited MBAS via 
the selected bearer network BN. The selection has been described in connec- 

25 tion with the simplified architecture. The traffic management unit of the visited 
MBAS decides to which bearer network the traffic should be directed. When a 
mobile node is away from its home network (out of the administrative range of 
its home MBAS), the home MBAS will act as the home agent and the visited 
MBAS acts as the foreign agent. The home MBAS tunnels the downlink traffic 

30 to the mobile node's visited MBAS. Route optimization can be used in this 
case. 

When a mobile node is in its home network, its home MBAS re- 
ceives IP traffic to the mobile node from the backbone network and forwards 
the traffic to the mobile node via a traffic distribution unit TDU in the home 
35 MBAS. In this respect, the home agent function of an MBAS differs from a 
conventional home agent in the mobile IP scheme, which does not need to 
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forward IP packets to a mobile node when the mobile node is in its home net- 
work. In most networks, when a mobile node is in its home network, it is on the 
same physical link with its home agent. The mobile node can directly receive 
all the packets addressed to it, and forwarding is not needed. But in some 
5 networks there is no direct physical link between a mobile node and the home 
agent, and the home agent must forward packets to the mobile node via a 
tunnel. 

Mobility support in a multi-bearer network 

In a bidirectional (non-broadcast) bearer network, a multi-bearer 
10 administration system MBAS can establish virtual links with all the cells via a 
corresponding interface unit IU. An MBAS can also establish virtual links with 
the broadcast cells within its MBAS area, and with their neighbouring cells. 

Let us now return briefly to Figures 10 and 11. Figure 10 illustrates 
broadcasting the ID number of the MBAS elements via a broadcast network 
15 (DAB or DVB). DVB cells 101, 102 and DAB cells 103, 104 broadcast the ID 
number of the MBAS element MBAS1, while DVB cells 105, 106 and DAB 
cells 107, 108 broadcast the ID number of the MBAS element MBAS2. Figure 
11 illustrates broadcasting the ID number of the MBAS elements via a non- 
broadcast (bidirectional) network (GSM, GPRS or UMTS). UMTS cells 111, 
20 GSM cells 112 and GPRS cells 113 broadcast the ID number of the MBAS 
element MBAS1, while UMTS cells 114, GSM cells 115 and GPRS cells 116 
broadcast the ID number of the MBAS element MBAS2. 

Different handover types 

A mobile node MN may face four different handover situations. In 
25 the first handover type, the MN is moving from one cell to another in a non- 
broadcast network, such as GPRS. This handover is supported by the non- 
broadcast network in question. The MBN has to take action only if the ID of the 
serving MBAS is broadcast over a non-broadcast network and the MN moves 
between cells broadcasting the ID of different MBAS elements. If the MN 
30 moves between different MBAS areas, it should register with its home MBAS 
and the new visited MBAS after completing the inter-cell handover. 

In the second handover type, the MN is moving from one cell to an- 
other in a broadcast network (DAB or DVB) such that both cells belong to the 
same network (such as DAB) and to the same MBAS area. In this case, the 
35 mobility management unit MMU of a visited MBAS and the corresponding enti- 
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ties of the mobile node are responsible for handling micro-mobility. A general 
procedure for such a handover is as follows: 

1. The mobile node detects signal deterioration. 

2. The mobile node measures the signal strength in the neighbour- 
5 ing cells, makes a list of recommended cells, and sends the measurement 

data (signal strength and cell ID) as well as the recommendation list to the 
mobility management unit MMU in the visited MBAS. 

3. The mobility management unit MMU of the visited MBAS deter- 
mines the available resources and instructs the mobile node to perform an in- 

10 tra-system or inter-system handover (or roaming). 

4. After the MBAS has sent a handover command to the MN, the 
MBAS may optionally buffer incoming data to the MN until the MN acknowl- 
edges the attachment to the new cell. As the inter-cell handover takes place 
locally, the time from the handover command to the acknowledgement is 

15 short, and a reasonably small buffer is sufficient. 

5. When the mobile node is attached to a new cell, the Mobility 
management unit MMU directs the traffic distribution unit TDU to route the 
traffic to the new cell. From now on, the traffic is routed to the new cell. 

The term 'roaming* in general means simply moving from one net- 

20 work to another. The term 'handover' means handing over an ongoing call 
(which can be a voice call, a data call, a multimedia call or the like). Roaming 
support can be achieved with relative ease because there is no ongoing traffic. 

Figure 16 illustrates a handover between two DVB cells belonging 
to the same MBAS area. The solid single-headed arrows denote the connec- 

25 tion before the handover, and the dashed single-headed arrows denote the 
connection after the handover. The dotted double-headed arrows denote sig- 
nalling connections by which the mobile node reports the signal strengths of 
the cells it can receive. 

In the third handover type, the MN is moving from one cell to an- 

30 other within one MBAS area but in different bearer networks. For example, the 
MN may move from a DAB cell to a DVB cell. This type of handover takes 
place when the MN is moving out of the coverage range of one network or 
when the neighbouring cell that belongs to the same network is congested. 
This type of handover follows the same procedure as the second type of han- 

35 dover. 
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In the fourth handover type, the MN is moving from one MBAS area 
to another. In other words, the MN moves between cells having different 
master MBAS elements. Normally, the master MBAS of the MN's active cell 
should act as the MN's visited MBAS because it is the MBAS having the 
5 shortest distance to the interface unit of the active cell. In this context, 
'distance' may mean physical distance or a number of hops, depending on the 
implementation. To achieve a smooth handover between MBAS elements, the 
MN does not have to change its visited MBAS during an inter-MBAS-area 
handover. Instead, it should first perform an inter-cell handover, aided by its 
10 old MBAS (the master MBAS of the previous cell). When the inter-cell hando- 
ver has been performed successfully, the MN can perform normal Mobile IP 
registration with the new visited MBAS (the MBAS of the MN's new cell) and 
its home MBAS. 

Such a two-phase handover has two major benefits. The handover 

15 is fast and data loss is minimized. The inter-cell handover according to this 
preferred embodiment of the invention dispenses with registration and authen- 
tication with a foreign agent and a home agent. Such operations can be very 
time-consuming, especially when the MN's home MBAS is in another MBN, lo- 
cated far away. Another feature improving the speed of the handover is the 

20 fact that during the mobile node's binding update the Mobile IP registration 
process is carried out in parallel with user data transfer. In other words, the 
MN does not have to stop data reception during the registration process. The 
reduced duration of the handover and the parallel registration and data trans- 
fer processes eliminate or at least significantly reduce data loss during an in- 

25 ter-AS handover. Further, when the MN updates its mobility binding, its user 
traffic is delivered via the same broadcast cell, and the MN does not miss any 
packets before or after the mobility binding update. 

A failure to follow the above-specified two-phase handover proce- 
dure, ie an attempt to perform an inter-MBAS handover before starting to re- 

30 ceive data from the new cell, may result in service degradation because of the 
time involved in the inter-MBAS handover. An example of such a handover is 
a handover between cells belonging to different MMAs (Mobility Management 
Agents) in the MEMO concept. 

Figures 17A and 17B further illustrate the two-phase handover be- 

35 tween two DVB cells. Figure 17A illustrates a first phase in which the mobile 
node MN performs a normal inter-cell handover. During the first phase, the old 
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visited MBAS, MBAS2, is still used for serving the mobile node. The mobility 
management unit inside the old MBAS2 instructs the mobile node to perform 
an inter-cell handover. Figure 17B illustrates a second phase in which the mo- 
bile node performs a mobility binding update by following normal mobile-IP 
5 procedures. Because downlink traffic is always forwarded via the same cell 
during an inter-MBAS handover, the handover will not cause packet loss. In 
more detail, an inter-MBAS handover in a situation as shown in Figures 17A 
and 17B comprises the following steps. 

1. A mobile node MN, which is registered with MBAS2, measures 
10 the signal strength (or some other criterion of signal quality, such as bit error 
ratio) of DVB cells 171 and 172. The former broadcasts the ID of MBAS2 and 
the latter broadcasts the ID of MBAS3. MBAS1 is the mobile node's home 
MBAS. The mobile node detects that the signal quality of DVB cell 172 is so 
much better that a handover is justified. The signal quality measurements and 
15 a handover request are sent to MBAS2. 

2. The mobility management unit MMU in MBAS2 decides to hand 
over the mobile node's traffic to DVB cell 172. The mobility management unit 
MMU in MBAS2 assists the mobile node MN in performing an inter-cell hando- 
ver to DVB cell 172. After the inter-cell handover, the MN begins to receive 

20 data from cell 172. 

3. The mobile node MN detects that cell 172 broadcasts the ID of 
MBAS3, ie the ID of a different MBAS from the one the MN is registered with. 

4. The mobile node measures the signal quality of the cells broad- 
casting the ID of MBAS2, and other neighbouring cells. If the signal quality of 

25 cell 172 is much better than the quality of all neighbouring cells, or if the cells 
which broadcast the ID of MBAS2 are too weak to receive, the MN begins to 
perform an inter-MBAS handover. 

5. The mobile node sends a registration request to MBAS1 (its 
home MBAS) and to MBAS3 (a visited MBAS). The registration request per se 
can be implemented by conventional mobile-IP procedures. In the registration 
request, the IP address of MBAS 3 is provided as the mobile node's care-of- 
address. During the registration process, the mobile node keeps receiving 
traffic from cell 172 (via MBAS2). 

6. MBAS1 (the mobile node's home MBAS) performs a binding up- 
date. In other words, it registers MBAS 3 as the mobile node's foreign agent. 
Before the binding update. MBAS2 acts as the mobile node's visited MBAS. 
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After the binding update, MBAS3 acts as the mobile node's visited MBAS and 
all user traffic to the MN is routed via MBAS3. From this point on, the mobility 
management unit of MBAS3 is responsible for handling the mobile node MN. 

7. Optionally, the mobile node can send a de-registration message 
5 to MBAS2, informing it about the successful handover. Alternatively, each 
MBAS may employ a mobile-node-specific timer. If the MBAS receives nothing 
from a mobile node, the MBAS can assume that the mobile node has been 
switched off or it has moved elsewhere. 

An essential feature of the above-described inter-MBAS handover 
10 is that the mobile node receives service from a new MBAS during the entire 
handover process. This is in stark contrast to the scheme outlined in reference 
1 (the MEMO project), in which a mobile node must register with a PSTS 
(personal services transport server) before receiving service from a cell under 
that element. In other words, a system according to reference 1 is not able to 
15 hand over an ongoing call, at least not without packet loss. 

To avoid unnecessary back-and-forth mobility binding updates for 
mobile nodes wandering around a border area, some kind of hysteresis can be 
employed. For example, after a handover between cells in different MBAS ar- 
eas, a mobile node may wait some time before it begins a mobility binding up- 
date. During the waiting time, the MN may monitor the signal strength of its old 
cell and new cell to determine whether it is really moving away from its old cell. 
If a mobile node is staying in the border area between two MBAS elements for 
an extended period of time, it can request the old visited MBAS to support it 
without re-registration with its new visited MBAS. 

A mobile node according to the enhanced architecture of the inven- 
tion should be aware of the handover logic. When the mobile node is handed 
over to a cell which belongs to a different administration system (PSTS in the 
MEMO concept, MBAS in the present invention) than the one which served 
the mobile node's old cell, the mobile node should start performing mobile-IP 
registration and a binding update within a certain time limit. If the mobile node 
is uncertain whether it will soon return to the area of the old administration 
system, it should send the administration system a request for extending sup- 
port time. 

The enhanced architecture has been described in connection with a 
35 single network operator. On the basis of the description, a skilled reader can 
implement a multi-bearer network which can be at least partially shared by 
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multiple network operators. In this case, the operators can share at least some 
bearer networks and/or network elements, most notably the interface units IU, 
while each operator has its own MBAS element. 

Reference: 

1. MEMO network documentation (collectively referred to as the 
"MEMO concept"), available at http: / /memo, lboro. ac . uk 
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Claims 

1. A network element (MBAS) for supporting mobility of a mobile 
node (MN) in a system (MBN) which comprises or is connected to several dif- 
ferent bearer networks (BN), the bearer networks comprising at least one uni- 
directional network (DAB, DVB) and at least one bidirectional network (GSM 
GPRS, UMTS); 

the network element (MBAS) being characterized^: 
at least one support area, each support area comprising one or 
more cells in said bearer networks (BN); 

a home agent function (HA) for acting as a home agent to mobile 
nodes at home and a foreign agent function (FA) for acting as a foreign agent 
to visiting mobile nodes, the home agent and foreign agent functions being 
substantially compatible with mobile-IP protocol; and 

a handover logic (HL) for handing over a mobile node to a neigh- 
15 bouring network element, the handover logic being adapted to provide con- 
tinuous service for a mobile node after it has moved to the support area of the 
neighbouring network element and before it has re-registered with its home 
agent. 



10 



20 



2. A network element (MBAS) for supporting mobility of a mobile 
node (MN) in a system (MBN) which comprises or is connected to several dif- 
ferent bearer networks (BN), the bearer networks comprising at least one uni- 
directional network (DAB, DVB) and at least one bidirectional network (GSM 
GPRS, UMTS); 

the network element being characterized by 
25 at ,east one support area, each support area comprising one or 

more cells in said bearer networks (BN); 

first connections (71) to the cells in its own support area and sec- 
ond connections (72) to at least a subset of cells in the support area of each 
neighbouring network element, the second connections having one or more 
30 limitations compared to the first connections; and 

handover logic (HL) for handing over an ongoing call of the mobile 
node to a neighbouring network element by using the second connections 
(72). 

3. A network element according to claim ^characterized by 
35 first connections (71) to the cells in its own support area and second connec- 
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tions (72) to at least a subset of cells in the support area of each neighbouring 
network element, the second connections having one or more limitations com- 
pared to the first connections. 

4. A network element according to claim 2 or 3, characterized 
5 in that said second connections (72) are limited in time. 

5. A network element according to claim 4, characterized in 
that said second connections (72) are limited to a predetermined time after a 
handover to a neighbouring network element. 

6. A network element according to any one of claims 2 to 4, cha- 
10 racterized in that said second connections (72) are limited by the fact that 

no new sessions are granted via them. 

<■ 

7. A network element according to any one of the preceding claims, 
characterized in that the subset of cells substantially consists of one or a 
few cells along the border of the support area of the network element in ques- 

15 tion and its neighbour. 

8. A network element according to any one of the preceding claims, 
characterized by: 

a traffic management function (TMF) for selecting an optimal bearer 
network (BN) for a data packet (DP) between the MBN and the mobile node 
20 (MN) based on: 

the quality-of-service requirement (QoS) of the data packet (DP) in 

question; 

traffic load data (41) related to the multiple bearers; 
interface unit preference information (PIU, 42); and 
25 bearer type preference information (PBT, 43). 

9. A telecommunications system for conveying mobile-IP traffic to a 
mobile node (MN), wherein the system comprises or is connected to several 
different cellular bearer networks (BN) t the bearer networks comprising at least 
one unidirectional network (DAB, DVB) and at least one bidirectional network 

30 (GSM, GPRS, UMTS); 

characterized by 
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a network element (MBAS) which is associated with at least one 
support area, each of which comprises one or more cells in the bearer net- 
works (BN); 

the network element (MBAS) having first connections (71) to the 
5 cells in its own support area and second connections (72) to at least a subset 
of cells in the support area of each neighbouring network element, the second 
connections (72) having one or more limitations compared to the first connec- 
tions (71). 

10. A handover method for handing over an ongoing call of a mobile 
10 node (MN) in a system (MBN) which comprises or is connected to several dif- 
ferent bearer networks (BN), the bearer networks comprising at least one uni- 
directional network (DAB, DVB) and at least one bidirectional network (GSM, 
GPRS, UMTS); 

characterized by 
15 controlling the handover method at least in part by a network ele- 

ment (MBAS) which is associated with at least one support area, each of 
which comprises one or more cells in the bearer networks (BN); 

providing the network element (MBAS) with first connections (71) to 
the cells in its own support area and second connections (72) to at least a 
20 subset of cells in the support area of each neighbouring network element; 

associating the mobile node with a home network element; 
handing over the mobile node (MS) to a neighbouring cell; and 
using the second connections (72) to provide continuous service for 
the mobile node after it has moved to the support area of a new network ele- 
25 ment and before it has re-registered with its home network element. 

1 1 . A handover method for handing over an ongoing call of a mobile 
node (MN) from a first subnetwork to second subnetwork, each subnetwork 
comprising one or more access points (AP) and a group of cells under one 
foreign agent function (FA, MBAS); 
30 the handover method comprising conveying said call between the 

foreign agent function (FA, MBAS) and an access point (AP) via at least one 
first connection (71); 

characterized by 

a first phase in which the call is handed over from a cell (73, 171) in 
35 the first subnetwork to a cell (74, 172) in the second subnetwork; 
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a second phase in which the call is handed over from a foreign 
agent function (FA, MBAS2) in the in the first subnetwork to a foreign agent 
function (FA, MBAS3) in the in the second subnetwork; and 

using at least one second connection (72) for conveying said call 
between the foreign agent function (FA, MBAS2) in the in the first subnetwork 
and the cell (74, 172) in the second subnetwork, the at least one second con- 
nection (72) being more limited than the first connection (71). 

12. A hierarchical wireless cellular IP network for handling a call 
to/from a mobile node (MN), the network comprising: 

a home agent function (HA) for registering the mobile node; 

several foreign agent functions (FA, AS1, AS2, MBAS); 

one or more subnetworks (SNW) under each foreign agent function, 
each subnetwork comprising at least one cell and having at least one access 
point (AP, AP1a ... AP2b); and 

at least one first connection (71) between each foreign agent func- 
tion and each access point under it; 
characterized by 

at least one second connection (72) for temporary call support be- 
tween a foreign agent function (AS1) of one subnetwork and an access point 
(AP2a) of a neighbouring subnetwork, the at least one second connection (72) 
being more limited than the first connection (71); 

whereby the network is capable of smooth handover of the call be- 
tween subnetworks until the mobile node re-registers with the home agent 
function (HA). 



13. A mobile node (MN), operable to hand over an ongoing call 
from a first subnetwork to second subnetwork, each subnetwork comprising 
one or more access points (AP) and a group of cells under one foreign agent 
function (FA, MBAS); 

characterized by being adapted to: 

hand over a call to/from the mobile node in two phases, namely a 
first phase for handing over the call from a cell (73, 171) in the first subnetwork 
to a cell (74, 172) in the second subnetwork, and a second phase for handing 
over the call from a foreign agent function (FA, MBAS2) in the in the first sub- 
network to a foreign agent function (FA, MBAS3) in the in the second subnet- 
35 work; 
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perform a re-registration with its home agent function (HA) within a 
predetermined time limit from the second phase, and to: 

communicate with the foreign agent function (FA, MBAS2) in the in 
the first subnetwork until it the re-registration with its home agent function is 
5 completed. 

14. A mobile node according to claim 13, characterized by be- 
ing adapted to send the foreign agent function (FA, MBAS2) in the first sub- 
network a request for extending communication time if the mobile node re- 
mains in a border area between the subnetworks for a time likely to exceed 
10 the predetermined time limit. 
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